home *** CD-ROM | disk | FTP | other *** search
/ AmigActive 24 / AACD 24.iso / AACD / Programming / gcc-2.95.3-3 / info / g77.info-18 < prev    next >
Encoding:
GNU Info File  |  2001-07-15  |  47.8 KB  |  1,148 lines
  1. This is Info file f/g77.info, produced by Makeinfo version 1.68 from
  2. the input file ./f/g77.texi.
  3.  
  4. INFO-DIR-SECTION Programming
  5. START-INFO-DIR-ENTRY
  6. * g77: (g77).                  The GNU Fortran compiler.
  7. END-INFO-DIR-ENTRY
  8.    This file documents the use and the internals of the GNU Fortran
  9. (`g77') compiler.  It corresponds to the GCC-2.95 version of `g77'.
  10.  
  11.    Published by the Free Software Foundation 59 Temple Place - Suite 330
  12. Boston, MA 02111-1307 USA
  13.  
  14.    Copyright (C) 1995-1999 Free Software Foundation, Inc.
  15.  
  16.    Permission is granted to make and distribute verbatim copies of this
  17. manual provided the copyright notice and this permission notice are
  18. preserved on all copies.
  19.  
  20.    Permission is granted to copy and distribute modified versions of
  21. this manual under the conditions for verbatim copying, provided also
  22. that the sections entitled "GNU General Public License," "Funding for
  23. Free Software," and "Protect Your Freedom--Fight `Look And Feel'" are
  24. included exactly as in the original, and provided that the entire
  25. resulting derived work is distributed under the terms of a permission
  26. notice identical to this one.
  27.  
  28.    Permission is granted to copy and distribute translations of this
  29. manual into another language, under the above conditions for modified
  30. versions, except that the sections entitled "GNU General Public
  31. License," "Funding for Free Software," and "Protect Your Freedom--Fight
  32. `Look And Feel'", and this permission notice, may be included in
  33. translations approved by the Free Software Foundation instead of in the
  34. original English.
  35.  
  36.    Contributed by James Craig Burley (<craig@jcb-sc.com>).  Inspired by
  37. a first pass at translating `g77-0.5.16/f/DOC' that was contributed to
  38. Craig by David Ronis (<ronis@onsager.chem.mcgill.ca>).
  39.  
  40. 
  41. File: g77.info,  Node: Adding Options,  Next: Projects,  Prev: Service,  Up: Top
  42.  
  43. Adding Options
  44. **************
  45.  
  46.    To add a new command-line option to `g77', first decide what kind of
  47. option you wish to add.  Search the `g77' and `gcc' documentation for
  48. one or more options that is most closely like the one you want to add
  49. (in terms of what kind of effect it has, and so on) to help clarify its
  50. nature.
  51.  
  52.    * *Fortran options* are options that apply only when compiling
  53.      Fortran programs.  They are accepted by `g77' and `gcc', but they
  54.      apply only when compiling Fortran programs.
  55.  
  56.    * *Compiler options* are options that apply when compiling most any
  57.      kind of program.
  58.  
  59.    *Fortran options* are listed in the file `egcs/gcc/f/lang-options.h',
  60. which is used during the build of `gcc' to build a list of all options
  61. that are accepted by at least one language's compiler.  This list goes
  62. into the `lang_options' array in `gcc/toplev.c', which uses this array
  63. to determine whether a particular option should be offered to the
  64. linked-in front end for processing by calling `lang_option_decode',
  65. which, for `g77', is in `egcs/gcc/f/com.c' and just calls
  66. `ffe_decode_option'.
  67.  
  68.    If the linked-in front end "rejects" a particular option passed to
  69. it, `toplev.c' just ignores the option, because *some* language's
  70. compiler is willing to accept it.
  71.  
  72.    This allows commands like `gcc -fno-asm foo.c bar.f' to work, even
  73. though Fortran compilation does not currently support the `-fno-asm'
  74. option; even though the `f771' version of `lang_decode_option' rejects
  75. `-fno-asm', `toplev.c' doesn't produce a diagnostic because some other
  76. language (C) does accept it.
  77.  
  78.    This also means that commands like `g77 -fno-asm foo.f' yield no
  79. diagnostics, despite the fact that no phase of the command was able to
  80. recognize and process `-fno-asm'--perhaps a warning about this would be
  81. helpful if it were possible.
  82.  
  83.    Code that processes Fortran options is found in `egcs/gcc/f/top.c',
  84. function `ffe_decode_option'.  This code needs to check positive and
  85. negative forms of each option.
  86.  
  87.    The defaults for Fortran options are set in their global
  88. definitions, also found in `egcs/gcc/f/top.c'.  Many of these defaults
  89. are actually macros defined in `egcs/gcc/f/target.h', since they might
  90. be machine-specific.  However, since, in practice, GNU compilers should
  91. behave the same way on all configurations (especially when it comes to
  92. language constructs), the practice of setting defaults in `target.h' is
  93. likely to be deprecated and, ultimately, stopped in future versions of
  94. `g77'.
  95.  
  96.    Accessor macros for Fortran options, used by code in the `g77' FFE,
  97. are defined in `egcs/gcc/f/top.h'.
  98.  
  99.    *Compiler options* are listed in `gcc/toplev.c' in the array
  100. `f_options'.  An option not listed in `lang_options' is looked up in
  101. `f_options' and handled from there.
  102.  
  103.    The defaults for compiler options are set in the global definitions
  104. for the corresponding variables, some of which are in `gcc/toplev.c'.
  105.  
  106.    You can set different defaults for *Fortran-oriented* or
  107. *Fortran-reticent* compiler options by changing the source code of
  108. `g77' and rebuilding.  How to do this depends on the version of `g77':
  109.  
  110. `G77 0.5.24 (EGCS 1.1)'
  111. `G77 0.5.25 (EGCS 1.2)'
  112.      Change the `lang_init_options' routine in `egcs/gcc/f/com.c'.
  113.  
  114.      (Note that these versions of `g77' perform internal consistency
  115.      checking automatically when the `-fversion' option is specified.)
  116.  
  117. `G77 0.5.23'
  118. `G77 0.5.24 (EGCS 1.0)'
  119.      Change the way `f771' handles the `-fset-g77-defaults' option,
  120.      which is always provided as the first option when called by `g77'
  121.      or `gcc'.
  122.  
  123.      This code is in `ffe_decode_options' in `egcs/gcc/f/top.c'.  Have
  124.      it change just the variables that you want to default to a
  125.      different setting for Fortran compiles compared to compiles of
  126.      other languages.
  127.  
  128.      The `-fset-g77-defaults' option is passed to `f771' automatically
  129.      because of the specification information kept in
  130.      `egcs/gcc/f/lang-specs.h'.  This file tells the `gcc' command how
  131.      to recognize, in this case, Fortran source files (those to be
  132.      preprocessed, and those that are not), and further, how to invoke
  133.      the appropriate programs (including `f771') to process those
  134.      source files.
  135.  
  136.      It is in `egcs/gcc/f/lang-specs.h' that `-fset-g77-defaults',
  137.      `-fversion', and other options are passed, as appropriate, even
  138.      when the user has not explicitly specified them.  Other "internal"
  139.      options such as `-quiet' also are passed via this mechanism.
  140.  
  141. 
  142. File: g77.info,  Node: Projects,  Next: Front End,  Prev: Adding Options,  Up: Top
  143.  
  144. Projects
  145. ********
  146.  
  147.    If you want to contribute to `g77' by doing research, design,
  148. specification, documentation, coding, or testing, the following
  149. information should give you some ideas.  More relevant information
  150. might be available from `ftp://alpha.gnu.org/gnu/g77/projects/'.
  151.  
  152. * Menu:
  153.  
  154. * Efficiency::               Make `g77' itself compile code faster.
  155. * Better Optimization::      Teach `g77' to generate faster code.
  156. * Simplify Porting::         Make `g77' easier to configure, build,
  157.                              and install.
  158. * More Extensions::          Features many users won't know to ask for.
  159. * Machine Model::            `g77' should better leverage `gcc'.
  160. * Internals Documentation::  Make maintenance easier.
  161. * Internals Improvements::   Make internals more robust.
  162. * Better Diagnostics::       Make using `g77' on new code easier.
  163.  
  164. 
  165. File: g77.info,  Node: Efficiency,  Next: Better Optimization,  Up: Projects
  166.  
  167. Improve Efficiency
  168. ==================
  169.  
  170.    Don't bother doing any performance analysis until most of the
  171. following items are taken care of, because there's no question they
  172. represent serious space/time problems, although some of them show up
  173. only given certain kinds of (popular) input.
  174.  
  175.    * Improve `malloc' package and its uses to specify more info about
  176.      memory pools and, where feasible, use obstacks to implement them.
  177.  
  178.    * Skip over uninitialized portions of aggregate areas (arrays,
  179.      `COMMON' areas, `EQUIVALENCE' areas) so zeros need not be output.
  180.      This would reduce memory usage for large initialized aggregate
  181.      areas, even ones with only one initialized element.
  182.  
  183.      As of version 0.5.18, a portion of this item has already been
  184.      accomplished.
  185.  
  186.    * Prescan the statement (in `sta.c') so that the nature of the
  187.      statement is determined as much as possible by looking entirely at
  188.      its form, and not looking at any context (previous statements,
  189.      including types of symbols).  This would allow ripping out of the
  190.      statement-confirmation, symbol retraction/confirmation, and
  191.      diagnostic inhibition mechanisms.  Plus, it would result in
  192.      much-improved diagnostics.  For example, `CALL
  193.      some-intrinsic(...)', where the intrinsic is not a subroutine
  194.      intrinsic, would result actual error instead of the
  195.      unimplemented-statement catch-all.
  196.  
  197.    * Throughout `g77', don't pass line/column pairs where a simple
  198.      `ffewhere' type, which points to the error as much as is desired
  199.      by the configuration, will do, and don't pass `ffelexToken' types
  200.      where a simple `ffewhere' type will do.  Then, allow new default
  201.      configuration of `ffewhere' such that the source line text is not
  202.      preserved, and leave it to things like Emacs' next-error function
  203.      to point to them (now that `next-error' supports column, or,
  204.      perhaps, character-offset, numbers).  The change in calling
  205.      sequences should improve performance somewhat, as should not
  206.      having to save source lines.  (Whether this whole item will
  207.      improve performance is questionable, but it should improve
  208.      maintainability.)
  209.  
  210.    * Handle `DATA (A(I),I=1,1000000)/1000000*2/' more efficiently,
  211.      especially as regards the assembly output.  Some of this might
  212.      require improving the back end, but lots of improvement in
  213.      space/time required in `g77' itself can be fairly easily obtained
  214.      without touching the back end.  Maybe type-conversion, where
  215.      necessary, can be speeded up as well in cases like the one shown
  216.      (converting the `2' into `2.').
  217.  
  218.    * If analysis shows it to be worthwhile, optimize `lex.c'.
  219.  
  220.    * Consider redesigning `lex.c' to not need any feedback during
  221.      tokenization, by keeping track of enough parse state on its own.
  222.  
  223. 
  224. File: g77.info,  Node: Better Optimization,  Next: Simplify Porting,  Prev: Efficiency,  Up: Projects
  225.  
  226. Better Optimization
  227. ===================
  228.  
  229.    Much of this work should be put off until after `g77' has all the
  230. features necessary for its widespread acceptance as a useful F77
  231. compiler.  However, perhaps this work can be done in parallel during
  232. the feature-adding work.
  233.  
  234.    * Do the equivalent of the trick of putting `extern inline' in front
  235.      of every function definition in `libg2c' and #include'ing the
  236.      resulting file in `f2c'+`gcc'--that is, inline all
  237.      run-time-library functions that are at all worth inlining.  (Some
  238.      of this has already been done, such as for integral
  239.      exponentiation.)
  240.  
  241.    * When doing `CHAR_VAR = CHAR_FUNC(...)', and it's clear that types
  242.      line up and `CHAR_VAR' is addressable or not a `VAR_DECL', make
  243.      `CHAR_VAR', not a temporary, be the receiver for `CHAR_FUNC'.
  244.      (This is now done for `COMPLEX' variables.)
  245.  
  246.    * Design and implement Fortran-specific optimizations that don't
  247.      really belong in the back end, or where the front end needs to
  248.      give the back end more info than it currently does.
  249.  
  250.    * Design and implement a new run-time library interface, with the
  251.      code going into `libgcc' so no special linking is required to link
  252.      Fortran programs using standard language features.  This library
  253.      would speed up lots of things, from I/O (using precompiled formats,
  254.      doing just one, or, at most, very few, calls for arrays or array
  255.      sections, and so on) to general computing (array/section
  256.      implementations of various intrinsics, implementation of commonly
  257.      performed loops that aren't likely to be optimally compiled
  258.      otherwise, etc.).
  259.  
  260.      Among the important things the library would do are:
  261.  
  262.         * Be a one-stop-shop-type library, hence shareable and usable
  263.           by all, in that what are now library-build-time options in
  264.           `libg2c' would be moved at least to the `g77' compile phase,
  265.           if not to finer grains (such as choosing how list-directed
  266.           I/O formatting is done by default at `OPEN' time, for
  267.           preconnected units via options or even statements in the main
  268.           program unit, maybe even on a per-I/O basis with appropriate
  269.           pragma-like devices).
  270.  
  271.    * Probably requiring the new library design, change interface to
  272.      normally have `COMPLEX' functions return their values in the way
  273.      `gcc' would if they were declared `__complex__ float', rather than
  274.      using the mechanism currently used by `CHARACTER' functions
  275.      (whereby the functions are compiled as returning void and their
  276.      first arg is a pointer to where to store the result).  (Don't
  277.      append underscores to external names for `COMPLEX' functions in
  278.      some cases once `g77' uses `gcc' rather than `f2c' calling
  279.      conventions.)
  280.  
  281.    * Do something useful with `doiter' references where possible.  For
  282.      example, `CALL FOO(I)' cannot modify `I' if within a `DO' loop
  283.      that uses `I' as the iteration variable, and the back end might
  284.      find that info useful in determining whether it needs to read `I'
  285.      back into a register after the call.  (It normally has to do that,
  286.      unless it knows `FOO' never modifies its passed-by-reference
  287.      argument, which is rarely the case for Fortran-77 code.)
  288.  
  289. 
  290. File: g77.info,  Node: Simplify Porting,  Next: More Extensions,  Prev: Better Optimization,  Up: Projects
  291.  
  292. Simplify Porting
  293. ================
  294.  
  295.    Making `g77' easier to configure, port, build, and install, either
  296. as a single-system compiler or as a cross-compiler, would be very
  297. useful.
  298.  
  299.    * A new library (replacing `libg2c') should improve portability as
  300.      well as produce more optimal code.  Further, `g77' and the new
  301.      library should conspire to simplify naming of externals, such as
  302.      by removing unnecessarily added underscores, and to
  303.      reduce/eliminate the possibility of naming conflicts, while making
  304.      debugger more straightforward.
  305.  
  306.      Also, it should make multi-language applications more feasible,
  307.      such as by providing Fortran intrinsics that get Fortran unit
  308.      numbers given C `FILE *' descriptors.
  309.  
  310.    * Possibly related to a new library, `g77' should produce the
  311.      equivalent of a `gcc' `main(argc, argv)' function when it compiles
  312.      a main program unit, instead of compiling something that must be
  313.      called by a library implementation of `main()'.
  314.  
  315.      This would do many useful things such as provide more flexibility
  316.      in terms of setting up exception handling, not requiring
  317.      programmers to start their debugging sessions with `breakpoint
  318.      MAIN__' followed by `run', and so on.
  319.  
  320.    * The GBE needs to understand the difference between alignment
  321.      requirements and desires.  For example, on Intel x86 machines,
  322.      `g77' currently imposes overly strict alignment requirements, due
  323.      to the back end, but it would be useful for Fortran and C
  324.      programmers to be able to override these *recommendations* as long
  325.      as they don't violate the actual processor *requirements*.
  326.  
  327. 
  328. File: g77.info,  Node: More Extensions,  Next: Machine Model,  Prev: Simplify Porting,  Up: Projects
  329.  
  330. More Extensions
  331. ===============
  332.  
  333.    These extensions are not the sort of things users ask for "by name",
  334. but they might improve the usability of `g77', and Fortran in general,
  335. in the long run.  Some of these items really pertain to improving `g77'
  336. internals so that some popular extensions can be more easily supported.
  337.  
  338.    * Look through all the documentation on the GNU Fortran language,
  339.      dialects, compiler, missing features, bugs, and so on.  Many
  340.      mentions of incomplete or missing features are sprinkled
  341.      throughout.  It is not worth repeating them here.
  342.  
  343.    * Consider adding a `NUMERIC' type to designate typeless numeric
  344.      constants, named and unnamed.  The idea is to provide a
  345.      forward-looking, effective replacement for things like the
  346.      old-style `PARAMETER' statement when people really need
  347.      typelessness in a maintainable, portable, clearly documented way.
  348.      Maybe `TYPELESS' would include `CHARACTER', `POINTER', and
  349.      whatever else might come along.  (This is not really a call for
  350.      polymorphism per se, just an ability to express limited, syntactic
  351.      polymorphism.)
  352.  
  353.    * Support `OPEN(...,KEY=(...),...)'.
  354.  
  355.    * Support arbitrary file unit numbers, instead of limiting them to 0
  356.      through `MXUNIT-1'.  (This is a `libg2c' issue.)
  357.  
  358.    * `OPEN(NOSPANBLOCKS,...)' is treated as
  359.      `OPEN(UNIT=NOSPANBLOCKS,...)', so a later `UNIT=' in the first
  360.      example is invalid.  Make sure this is what users of this feature
  361.      would expect.
  362.  
  363.    * Currently `g77' disallows `READ(1'10)' since it is an obnoxious
  364.      syntax, but supporting it might be pretty easy if needed.  More
  365.      details are needed, such as whether general expressions separated
  366.      by an apostrophe are supported, or maybe the record number can be
  367.      a general expression, and so on.
  368.  
  369.    * Support `STRUCTURE', `UNION', `MAP', and `RECORD' fully.
  370.      Currently there is no support at all for `%FILL' in `STRUCTURE'
  371.      and related syntax, whereas the rest of the stuff has at least
  372.      some parsing support.  This requires either major changes to
  373.      `libg2c' or its replacement.
  374.  
  375.    * F90 and `g77' probably disagree about label scoping relative to
  376.      `INTERFACE' and `END INTERFACE', and their contained procedure
  377.      interface bodies (blocks?).
  378.  
  379.    * `ENTRY' doesn't support F90 `RESULT()' yet, since that was added
  380.      after S8.112.
  381.  
  382.    * Empty-statement handling (10 ;;CONTINUE;;) probably isn't
  383.      consistent with the final form of the standard (it was vague at
  384.      S8.112).
  385.  
  386.    * It seems to be an "open" question whether a file, immediately
  387.      after being `OPEN'ed,is positioned at the beginning, the end, or
  388.      wherever--it might be nice to offer an option of opening to
  389.      "undefined" status, requiring an explicit absolute-positioning
  390.      operation to be performed before any other (besides `CLOSE') to
  391.      assist in making applications port to systems (some IBM?) that
  392.      `OPEN' to the end of a file or some such thing.
  393.  
  394. 
  395. File: g77.info,  Node: Machine Model,  Next: Internals Documentation,  Prev: More Extensions,  Up: Projects
  396.  
  397. Machine Model
  398. =============
  399.  
  400.    This items pertain to generalizing `g77''s view of the machine model
  401. to more fully accept whatever the GBE provides it via its configuration.
  402.  
  403.    * Switch to using `REAL_VALUE_TYPE' to represent floating-point
  404.      constants exclusively so the target float format need not be
  405.      required.  This means changing the way `g77' handles
  406.      initialization of aggregate areas having more than one type, such
  407.      as `REAL' and `INTEGER', because currently it initializes them as
  408.      if they were arrays of `char' and uses the bit patterns of the
  409.      constants of the various types in them to determine what to stuff
  410.      in elements of the arrays.
  411.  
  412.    * Rely more and more on back-end info and capabilities, especially
  413.      in the area of constants (where having the `g77' front-end's IL
  414.      just store the appropriate tree nodes containing constants might
  415.      be best).
  416.  
  417.    * Suite of C and Fortran programs that a user/administrator can run
  418.      on a machine to help determine the configuration for `g77' before
  419.      building and help determine if the compiler works (especially with
  420.      whatever libraries are installed) after building.
  421.  
  422. 
  423. File: g77.info,  Node: Internals Documentation,  Next: Internals Improvements,  Prev: Machine Model,  Up: Projects
  424.  
  425. Internals Documentation
  426. =======================
  427.  
  428.    Better info on how `g77' works and how to port it is needed.  Much
  429. of this should be done only after the redesign planned for 0.6 is
  430. complete.
  431.  
  432.    *Note Front End::, which contains some information on `g77'
  433. internals.
  434.  
  435. 
  436. File: g77.info,  Node: Internals Improvements,  Next: Better Diagnostics,  Prev: Internals Documentation,  Up: Projects
  437.  
  438. Internals Improvements
  439. ======================
  440.  
  441.    Some more items that would make `g77' more reliable and easier to
  442. maintain:
  443.  
  444.    * Generally make expression handling focus more on critical syntax
  445.      stuff, leaving semantics to callers.  For example, anything a
  446.      caller can check, semantically, let it do so, rather than having
  447.      `expr.c' do it.  (Exceptions might include things like diagnosing
  448.      `FOO(I--K:)=BAR' where `FOO' is a `PARAMETER'--if it seems
  449.      important to preserve the left-to-right-in-source order of
  450.      production of diagnostics.)
  451.  
  452.    * Come up with better naming conventions for `-D' to establish
  453.      requirements to achieve desired implementation dialect via
  454.      `proj.h'.
  455.  
  456.    * Clean up used tokens and `ffewhere's in `ffeglobal_terminate_1'.
  457.  
  458.    * Replace `sta.c' `outpooldisp' mechanism with `malloc_pool_use'.
  459.  
  460.    * Check for `opANY' in more places in `com.c', `std.c', and `ste.c',
  461.      and get rid of the `opCONVERT(opANY)' kludge (after determining if
  462.      there is indeed no real need for it).
  463.  
  464.    * Utility to read and check `bad.def' messages and their references
  465.      in the code, to make sure calls are consistent with message
  466.      templates.
  467.  
  468.    * Search and fix `&ffe...' and similar so that `ffe...ptr...' macros
  469.      are available instead (a good argument for wishing this could have
  470.      written all this stuff in C++, perhaps).  On the other hand, it's
  471.      questionable whether this sort of improvement is really necessary,
  472.      given the availability of tools such as Emacs and Perl, which make
  473.      finding any address-taking of structure members easy enough?
  474.  
  475.    * Some modules truly export the member names of their structures
  476.      (and the structures themselves), maybe fix this, and fix other
  477.      modules that just appear to as well (by appending `_', though it'd
  478.      be ugly and probably not worth the time).
  479.  
  480.    * Implement C macros `RETURNS(value)' and `SETS(something,value)' in
  481.      `proj.h' and use them throughout `g77' source code (especially in
  482.      the definitions of access macros in `.h' files) so they can be
  483.      tailored to catch code writing into a `RETURNS()' or reading from
  484.      a `SETS()'.
  485.  
  486.    * Decorate throughout with `const' and other such stuff.
  487.  
  488.    * All F90 notational derivations in the source code are still based
  489.      on the S8.112 version of the draft standard.  Probably should
  490.      update to the official standard, or put documentation of the rules
  491.      as used in the code...uh...in the code.
  492.  
  493.    * Some `ffebld_new' calls (those outside of `ffeexpr.c' or inside
  494.      but invoked via paths not involving `ffeexpr_lhs' or
  495.      `ffeexpr_rhs') might be creating things in improper pools, leading
  496.      to such things staying around too long or (doubtful, but possible
  497.      and dangerous) not long enough.
  498.  
  499.    * Some `ffebld_list_new' (or whatever) calls might not be matched by
  500.      `ffebld_list_bottom' (or whatever) calls, which might someday
  501.      matter.  (It definitely is not a problem just yet.)
  502.  
  503.    * Probably not doing clean things when we fail to `EQUIVALENCE'
  504.      something due to alignment/mismatch or other problems--they end up
  505.      without `ffestorag' objects, so maybe the backend (and other parts
  506.      of the front end) can notice that and handle like an `opANY' (do
  507.      what it wants, just don't complain or crash).  Most of this seems
  508.      to have been addressed by now, but a code review wouldn't hurt.
  509.  
  510. 
  511. File: g77.info,  Node: Better Diagnostics,  Prev: Internals Improvements,  Up: Projects
  512.  
  513. Better Diagnostics
  514. ==================
  515.  
  516.    These are things users might not ask about, or that need to be
  517. looked into, before worrying about.  Also here are items that involve
  518. reducing unnecessary diagnostic clutter.
  519.  
  520.    * When `FUNCTION' and `ENTRY' point types disagree (`CHARACTER'
  521.      lengths, type classes, and so on), `ANY'-ize the offending `ENTRY'
  522.      point and any *new* dummies it specifies.
  523.  
  524.    * Speed up and improve error handling for data when repeat-count is
  525.      specified.  For example, don't output 20 unnecessary messages
  526.      after the first necessary one for:
  527.  
  528.           INTEGER X(20)
  529.           CONTINUE
  530.           DATA (X(I), J= 1, 20) /20*5/
  531.           END
  532.  
  533.      (The `CONTINUE' statement ensures the `DATA' statement is
  534.      processed in the context of executable, not specification,
  535.      statements.)
  536.  
  537. 
  538. File: g77.info,  Node: Front End,  Next: Diagnostics,  Prev: Projects,  Up: Top
  539.  
  540. Front End
  541. *********
  542.  
  543.    This chapter describes some aspects of the design and implementation
  544. of the `g77' front end.  Much of the information below applies not to
  545. current releases of `g77', but to the 0.6 rewrite being designed and
  546. implemented as of late May, 1999.
  547.  
  548.    To find about things that are "To Be Determined" or "To Be Done",
  549. search for the string TBD.  If you want to help by working on one or
  550. more of these items, email me at <craig@jcb-sc.com>.  If you're
  551. planning to do more than just research issues and offer comments, see
  552. `http://www.gnu.org/software/contribute.html' for steps you might need
  553. to take first.
  554.  
  555. * Menu:
  556.  
  557. * Overview of Sources::
  558. * Overview of Translation Process::
  559. * Philosophy of Code Generation::
  560. * Two-pass Design::
  561. * Challenges Posed::
  562. * Transforming Statements::
  563. * Transforming Expressions::
  564. * Internal Naming Conventions::
  565.  
  566. 
  567. File: g77.info,  Node: Overview of Sources,  Next: Overview of Translation Process,  Up: Front End
  568.  
  569. Overview of Sources
  570. ===================
  571.  
  572.    The current directory layout includes the following:
  573.  
  574. `{No Value For "srcdir"}/gcc/'
  575.      Non-g77 files in gcc
  576.  
  577. `{No Value For "srcdir"}/gcc/f/'
  578.      GNU Fortran front end sources
  579.  
  580. `{No Value For "srcdir"}/libf2c/'
  581.      `libg2c' configuration and `g2c.h' file generation
  582.  
  583. `{No Value For "srcdir"}/libf2c/libF77/'
  584.      General support and math portion of `libg2c'
  585.  
  586. `{No Value For "srcdir"}/libf2c/libI77/'
  587.      I/O portion of `libg2c'
  588.  
  589. `{No Value For "srcdir"}/libf2c/libU77/'
  590.      Additional interfaces to Unix `libc' for `libg2c'
  591.  
  592.    Components of note in `g77' are described below.
  593.  
  594.    `f/' as a whole contains the source for `g77', while `libf2c/'
  595. contains a portion of the separate program `f2c'.  Note that the
  596. `libf2c' code is not part of the program `g77', just distributed with
  597. it.
  598.  
  599.    `f/' contains text files that document the Fortran compiler, source
  600. files for the GNU Fortran Front End (FFE), and some other stuff.  The
  601. `g77' compiler code is placed in `f/' because it, along with its
  602. contents, is designed to be a subdirectory of a `gcc' source directory,
  603. `gcc/', which is structured so that language-specific front ends can be
  604. "dropped in" as subdirectories.  The C++ front end (`g++'), is an
  605. example of this--it resides in the `cp/' subdirectory.  Note that the C
  606. front end (also referred to as `gcc') is an exception to this, as its
  607. source files reside in the `gcc/' directory itself.
  608.  
  609.    `libf2c/' contains the run-time libraries for the `f2c' program,
  610. also used by `g77'.  These libraries normally referred to collectively
  611. as `libf2c'.  When built as part of `g77', `libf2c' is installed under
  612. the name `libg2c' to avoid conflict with any existing version of
  613. `libf2c', and thus is often referred to as `libg2c' when the `g77'
  614. version is specifically being referred to.
  615.  
  616.    The `netlib' version of `libf2c/' contains two distinct libraries,
  617. `libF77' and `libI77', each in their own subdirectories.  In `g77',
  618. this distinction is not made, beyond maintaining the subdirectory
  619. structure in the source-code tree.
  620.  
  621.    `libf2c/' is not part of the program `g77', just distributed with it.
  622. It contains files not present in the official (`netlib') version of
  623. `libf2c', and also contains some minor changes made from `libf2c', to
  624. fix some bugs, and to facilitate automatic configuration, building, and
  625. installation of `libf2c' (as `libg2c') for use by `g77' users.  See
  626. `libf2c/README' for more information, including licensing conditions
  627. governing distribution of programs containing code from `libg2c'.
  628.  
  629.    `libg2c', `g77''s version of `libf2c', adds Dave Love's
  630. implementation of `libU77', in the `libf2c/libU77/' directory.  This
  631. library is distributed under the GNU Library General Public License
  632. (LGPL)--see the file `libf2c/libU77/COPYING.LIB' for more information,
  633. as this license governs distribution conditions for programs containing
  634. code from this portion of the library.
  635.  
  636.    Files of note in `f/' and `libf2c/' are described below:
  637.  
  638. `f/BUGS'
  639.      Lists some important bugs known to be in g77.  Or use Info (or GNU
  640.      Emacs Info mode) to read the "Actual Bugs" node of the `g77'
  641.      documentation:
  642.  
  643.           info -f f/g77.info -n "Actual Bugs"
  644.  
  645. `f/ChangeLog'
  646.      Lists recent changes to `g77' internals.
  647.  
  648. `libf2c/ChangeLog'
  649.      Lists recent changes to `libg2c' internals.
  650.  
  651. `f/NEWS'
  652.      Contains the per-release changes.  These include the user-visible
  653.      changes described in the node "Changes" in the `g77'
  654.      documentation, plus internal changes of import.  Or use:
  655.  
  656.           info -f f/g77.info -n News
  657.  
  658. `f/g77.info*'
  659.      The `g77' documentation, in Info format, produced by building
  660.      `g77'.
  661.  
  662.      All users of `g77' (not just installers) should read this, using
  663.      the `more' command if neither the `info' command, nor GNU Emacs
  664.      (with its Info mode), are available, or if users aren't yet
  665.      accustomed to using these tools.  All of these files are readable
  666.      as "plain text" files, though they're easier to navigate using
  667.      Info readers such as `info' and GNU Emacs Info mode.
  668.  
  669.    If you want to explore the FFE code, which lives entirely in `f/',
  670. here are a few clues.  The file `g77spec.c' contains the `g77'-specific
  671. source code for the `g77' command only--this just forms a variant of the
  672. `gcc' command, so, just as the `gcc' command itself does not contain
  673. the C front end, the `g77' command does not contain the Fortran front
  674. end (FFE).  The FFE code ends up in an executable named `f771', which
  675. does the actual compiling, so it contains the FFE plus the `gcc' back
  676. end (GBE), the latter to do most of the optimization, and the code
  677. generation.
  678.  
  679.    The file `parse.c' is the source file for `yyparse()', which is
  680. invoked by the GBE to start the compilation process, for `f771'.
  681.  
  682.    The file `top.c' contains the top-level FFE function `ffe_file' and
  683. it (along with top.h) define all `ffe_[a-z].*', `ffe[A-Z].*', and
  684. `FFE_[A-Za-z].*' symbols.
  685.  
  686.    The file `fini.c' is a `main()' program that is used when building
  687. the FFE to generate C header and source files for recognizing keywords.
  688. The files `malloc.c' and `malloc.h' comprise a memory manager that
  689. defines all `malloc_[a-z].*', `malloc[A-Z].*', and `MALLOC_[A-Za-z].*'
  690. symbols.
  691.  
  692.    All other modules named XYZ are comprised of all files named
  693. `XYZ*.EXT' and define all `ffeXYZ_[a-z].*', `ffeXYZ[A-Z].*', and
  694. `FFEXYZ_[A-Za-z].*' symbols.  If you understand all this,
  695. congratulations--it's easier for me to remember how it works than to
  696. type in these regular expressions.  But it does make it easy to find
  697. where a symbol is defined.  For example, the symbol
  698. `ffexyz_set_something' would be defined in `xyz.h' and implemented
  699. there (if it's a macro) or in `xyz.c'.
  700.  
  701.    The "porting" files of note currently are:
  702.  
  703. `proj.c'
  704. `proj.h'
  705.      This defines the "language" used by all the other source files,
  706.      the language being Standard C plus some useful things like
  707.      `ARRAY_SIZE' and such.
  708.  
  709. `target.c'
  710. `target.h'
  711.      These describe the target machine in terms of what data types are
  712.      supported, how they are denoted (to what C type does an
  713.      `INTEGER*8' map, for example), how to convert between them, and so
  714.      on.  Over time, versions of `g77' rely less on this file and more
  715.      on run-time configuration based on GBE info in `com.c'.
  716.  
  717. `com.c'
  718. `com.h'
  719.      These are the primary interface to the GBE.
  720.  
  721. `ste.c'
  722. `ste.h'
  723.      This contains code for implementing recognized executable
  724.      statements in the GBE.
  725.  
  726. `src.c'
  727. `src.h'
  728.      These contain information on the format(s) of source files (such
  729.      as whether they are never to be processed as case-insensitive with
  730.      regard to Fortran keywords).
  731.  
  732.    If you want to debug the `f771' executable, for example if it
  733. crashes, note that the global variables `lineno' and `input_filename'
  734. are usually set to reflect the current line being read by the lexer
  735. during the first-pass analysis of a program unit and to reflect the
  736. current line being processed during the second-pass compilation of a
  737. program unit.
  738.  
  739.    If an invocation of the function `ffestd_exec_end' is on the stack,
  740. the compiler is in the second pass, otherwise it is in the first.
  741.  
  742.    (This information might help you reduce a test case and/or work
  743. around a bug in `g77' until a fix is available.)
  744.  
  745. 
  746. File: g77.info,  Node: Overview of Translation Process,  Next: Philosophy of Code Generation,  Prev: Overview of Sources,  Up: Front End
  747.  
  748. Overview of Translation Process
  749. ===============================
  750.  
  751.    The order of phases translating source code to the form accepted by
  752. the GBE is:
  753.  
  754.   1. Stripping punched-card sources (`g77stripcard.c')
  755.  
  756.   2. Lexing (`lex.c')
  757.  
  758.   3. Stand-alone statement identification (`sta.c')
  759.  
  760.   4. Parsing (`stb.c' and `expr.c')
  761.  
  762.   5. Constructing (`stc.c')
  763.  
  764.   6. Collecting (`std.c')
  765.  
  766.   7. Expanding (`ste.c')
  767.  
  768.    To get a rough idea of how a particularly twisted Fortran statement
  769. gets treated by the passes, consider:
  770.  
  771.            FORMAT(I2 4H)=(J/
  772.           &   I3)
  773.  
  774.    The job of `lex.c' is to know enough about Fortran syntax rules to
  775. break the statement up into distinct lexemes without requiring any
  776. feedback from subsequent phases:
  777.  
  778.      `FORMAT'
  779.      `('
  780.      `I24H'
  781.      `)'
  782.      `='
  783.      `('
  784.      `J'
  785.      `/'
  786.      `I3'
  787.      `)'
  788.  
  789.    The job of `sta.c' is to figure out the kind of statement, or, at
  790. least, statement form, that sequence of lexemes represent.
  791.  
  792.    The sooner it can do this (in terms of using the smallest number of
  793. lexemes, starting with the first for each statement), the better,
  794. because that leaves diagnostics for problems beyond the recognition of
  795. the statement form to subsequent phases, which can usually better
  796. describe the nature of the problem.
  797.  
  798.    In this case, the `=' at "level zero" (not nested within parentheses)
  799. tells `sta.c' that this is an *assignment-form*, not `FORMAT',
  800. statement.
  801.  
  802.    An assignment-form statement might be a statement-function
  803. definition or an executable assignment statement.
  804.  
  805.    To make that determination, `sta.c' looks at the first two lexemes.
  806.  
  807.    Since the second lexeme is `(', the first must represent an array
  808. for this to be an assignment statement, else it's a statement function.
  809.  
  810.    Either way, `sta.c' hands off the statement to `stb.c' (either its
  811. statement-function parser or its assignment-statement parser).
  812.  
  813.    `stb.c' forms a statement-specific record containing the pertinent
  814. information.  That information includes a source expression and, for an
  815. assignment statement, a destination expression.  Expressions are parsed
  816. by `expr.c'.
  817.  
  818.    This record is passed to `stc.c', which copes with the implications
  819. of the statement within the context established by previous statements.
  820.  
  821.    For example, if it's the first statement in the file or after an
  822. `END' statement, `stc.c' recognizes that, first of all, a main program
  823. unit is now being lexed (and tells that to `std.c' before telling it
  824. about the current statement).
  825.  
  826.    `stc.c' attaches whatever information it can, usually derived from
  827. the context established by the preceding statements, and passes the
  828. information to `std.c'.
  829.  
  830.    `std.c' saves this information away, since the GBE cannot cope with
  831. information that might be incomplete at this stage.
  832.  
  833.    For example, `I3' might later be determined to be an argument to an
  834. alternate `ENTRY' point.
  835.  
  836.    When `std.c' is told about the end of an external (top-level)
  837. program unit, it passes all the information it has saved away on
  838. statements in that program unit to `ste.c'.
  839.  
  840.    `ste.c' "expands" each statement, in sequence, by constructing the
  841. appropriate GBE information and calling the appropriate GBE routines.
  842.  
  843.    Details on the transformational phases follow.  Keep in mind that
  844. Fortran numbering is used, so the first character on a line is column 1,
  845. decimal numbering is used, and so on.
  846.  
  847. * Menu:
  848.  
  849. * g77stripcard::
  850. * lex.c::
  851. * sta.c::
  852. * stb.c::
  853. * expr.c::
  854. * stc.c::
  855. * std.c::
  856. * ste.c::
  857.  
  858. * Gotchas (Transforming)::
  859. * TBD (Transforming)::
  860.  
  861. 
  862. File: g77.info,  Node: g77stripcard,  Next: lex.c,  Up: Overview of Translation Process
  863.  
  864. g77stripcard
  865. ------------
  866.  
  867.    The `g77stripcard' program handles removing content beyond column 72
  868. (adjustable via a command-line option), optionally warning about that
  869. content being something other than trailing whitespace or Fortran
  870. commentary.
  871.  
  872.    This program is needed because `lex.c' doesn't pay attention to
  873. maximum line lengths at all, to make it easier to maintain, as well as
  874. faster (for sources that don't depend on the maximum column length
  875. vis-a-vis trailing non-blank non-commentary content).
  876.  
  877.    Just how this program will be run--whether automatically for old
  878. source (perhaps as the default for `.f' files?)--is not yet determined.
  879.  
  880.    In the meantime, it might as well be implemented as a typical UNIX
  881. pipe.
  882.  
  883.    It should accept a `-fline-length-N' option, with the default line
  884. length set to 72.
  885.  
  886.    When the text it strips off the end of a line is not blank (not
  887. spaces and tabs), it should insert an additional comment line
  888. (beginning with `!', so it works for both fixed-form and free-form
  889. files) containing the text, following the stripped line.  The inserted
  890. comment should have a prefix of some kind, TBD, that distinguishes the
  891. comment as representing stripped text.  Users could use that to `sed'
  892. out such lines, if they wished--it seems silly to provide a
  893. command-line option to delete information when it can be so easily
  894. filtered out by another program.
  895.  
  896.    (This inserted comment should be designed to "fit in" well with
  897. whatever the Fortran community is using these days for preprocessor,
  898. translator, and other such products, like OpenMP.  What that's all
  899. about, and how `g77' can elegantly fit its special comment conventions
  900. into it all, is TBD as well.  We don't want to reinvent the wheel here,
  901. but if there turn out to be too many conflicting conventions, we might
  902. have to invent one that looks nothing like the others, but which offers
  903. their host products a better infrastructure in which to fit and coexist
  904. peacefully.)
  905.  
  906.    `g77stripcard' probably shouldn't do any tab expansion or other
  907. fancy stuff.  People can use `expand' or other pre-filtering if they
  908. like.  The idea here is to keep each stage quite simple, while providing
  909. excellent performance for "normal" code.
  910.  
  911.    (Code with junk beyond column 73 is not really "normal", as it comes
  912. from a card-punch heritage, and will be increasingly hard for
  913. tomorrow's Fortran programmers to read.)
  914.  
  915. 
  916. File: g77.info,  Node: lex.c,  Next: sta.c,  Prev: g77stripcard,  Up: Overview of Translation Process
  917.  
  918. lex.c
  919. -----
  920.  
  921.    To help make the lexer simple, fast, and easy to maintain, while
  922. also having `g77' generally encourage Fortran programmers to write
  923. simple, maintainable, portable code by maximizing the performance of
  924. compiling that kind of code:
  925.  
  926.    * There'll be just one lexer, for both fixed-form and free-form
  927.      source.
  928.  
  929.    * It'll care about the form only when handling the first 7 columns of
  930.      text, stuff like spaces between strings of alphanumerics, and how
  931.      lines are continued.
  932.  
  933.      Some other distinctions will be handled by subsequent phases, so
  934.      at least one of them will have to know which form is involved.
  935.  
  936.      For example, `I = 2 . 4' is acceptable in fixed form, and works in
  937.      free form as well given the implementation `g77' presently uses.
  938.      But the standard requires a diagnostic for it in free form, so the
  939.      parser has to be able to recognize that the lexemes aren't
  940.      contiguous (information the lexer *does* have to provide) and that
  941.      free-form source is being parsed, so it can provide the diagnostic.
  942.  
  943.      The `g77' lexer doesn't try to gather `2 . 4' into a single lexeme.
  944.      Otherwise, it'd have to know a whole lot more about how to parse
  945.      Fortran, or subsequent phases (mainly parsing) would have two
  946.      paths through lots of critical code--one to handle the lexeme `2',
  947.      `.', and `4' in sequence, another to handle the lexeme `2.4'.
  948.  
  949.    * It won't worry about line lengths (beyond the first 7 columns for
  950.      fixed-form source).
  951.  
  952.      That is, once it starts parsing the "statement" part of a line
  953.      (column 7 for fixed-form, column 1 for free-form), it'll keep
  954.      going until it finds a newline, rather than ignoring everything
  955.      past a particular column (72 or 132).
  956.  
  957.      The implication here is that there shouldn't *be* anything past
  958.      that last column, other than whitespace or commentary, because
  959.      users using typical editors (or viewing output as typically
  960.      printed) won't necessarily know just where the last column is.
  961.  
  962.      Code that has "garbage" beyond the last column (almost certainly
  963.      only fixed-form code with a punched-card legacy, such as code
  964.      using columns 73-80 for "sequence numbers") will have to be run
  965.      through `g77stripcard' first.
  966.  
  967.      Also, keeping track of the maximum column position while also
  968.      watching out for the end of a line *and* while reading from a file
  969.      just makes things slower.  Since a file must be read, and watching
  970.      for the end of the line is necessary (unless the typical input
  971.      file was preprocessed to include the necessary number of trailing
  972.      spaces), dropping the tracking of the maximum column position is
  973.      the only way to reduce the complexity of the pertinent code while
  974.      maintaining high performance.
  975.  
  976.    * ASCII encoding is assumed for the input file.
  977.  
  978.      Code written in other character sets will have to be converted
  979.      first.
  980.  
  981.    * Tabs (ASCII code 9) will be converted to spaces via the
  982.      straightforward approach.
  983.  
  984.      Specifically, a tab is converted to between one and eight spaces
  985.      as necessary to reach column N, where dividing `(N - 1)' by eight
  986.      results in a remainder of zero.
  987.  
  988.    * Linefeeds (ASCII code 10) mark the ends of lines.
  989.  
  990.    * A carriage return (ASCII code 13) is accept if it immediately
  991.      precedes a linefeed, in which case it is ignored.
  992.  
  993.      Otherwise, it is rejected (with a diagnostic).
  994.  
  995.    * Any other characters other than the above that are not part of the
  996.      GNU Fortran Character Set (*note Character Set::.)  are rejected
  997.      with a diagnostic.
  998.  
  999.      This includes backspaces, form feeds, and the like.
  1000.  
  1001.      (It might make sense to allow a form feed in column 1 as long as
  1002.      that's the only character on a line.  It certainly wouldn't seem
  1003.      to cost much in terms of performance.)
  1004.  
  1005.    * The end of the input stream (EOF) ends the current line.
  1006.  
  1007.    * The distinction between uppercase and lowercase letters will be
  1008.      preserved.
  1009.  
  1010.      It will be up to subsequent phases to decide to fold case.
  1011.  
  1012.      Current plans are to permit any casing for Fortran (reserved)
  1013.      keywords while preserving casing for user-defined names.  (This
  1014.      might not be made the default for `.f' files, though.)
  1015.  
  1016.      Preserving case seems necessary to provide more direct access to
  1017.      facilities outside of `g77', such as to C or Pascal code.
  1018.  
  1019.      Names of intrinsics will probably be matchable in any case,
  1020.      However, there probably won't be any option to require a
  1021.      particular mixed-case appearance of intrinsics (as there was for
  1022.      `g77' prior to version 0.6), because that's painful to maintain,
  1023.      and probably nobody uses it.
  1024.  
  1025.      (How `external SiN; r = sin(x)' would be handled is TBD.  I think
  1026.      old `g77' might already handle that pretty elegantly, but whether
  1027.      we can cope with allowing the same fragment to reference a
  1028.      *different* procedure, even with the same interface, via `s =
  1029.      SiN(r)', needs to be determined.  If it can't, we need to make
  1030.      sure that when code introduces a user-defined name, any intrinsic
  1031.      matching that name using a case-insensitive comparison is "turned
  1032.      off".)
  1033.  
  1034.    * Backslashes in `CHARACTER' and Hollerith constants are not allowed.
  1035.  
  1036.      This avoids the confusion introduced by some Fortran compiler
  1037.      vendors providing C-like interpretation of backslashes, while
  1038.      others provide straight-through interpretation.
  1039.  
  1040.      Some kind of lexical construct (TBD) will be provided to allow
  1041.      flagging of a `CHARACTER' (but probably not a Hollerith) constant
  1042.      that permits backslashes.  It'll necessarily be a prefix, such as:
  1043.  
  1044.           PRINT *, C'This line has a backspace \b here.'
  1045.           PRINT *, F'This line has a straight backslash \ here.'
  1046.  
  1047.      Further, command-line options might be provided to specify that
  1048.      one prefix or the other is to be assumed as the default for
  1049.      `CHARACTER' constants.
  1050.  
  1051.      However, it seems more helpful for `g77' to provide a program that
  1052.      converts prefix all constants (or just those containing
  1053.      backslashes) with the desired designation, so printouts of code
  1054.      can be read without knowing the compile-time options used when
  1055.      compiling it.
  1056.  
  1057.      If such a program is provided (let's name it `g77slash' for now),
  1058.      then a command-line option to `g77' should not be provided.
  1059.      (Though, given that it'll be easy to implement, it might be hard
  1060.      to resist user requests for it "to compile faster than if we have
  1061.      to invoke another filter".)
  1062.  
  1063.      This program would take a command-line option to specify the
  1064.      default interpretation of slashes, affecting which prefix it uses
  1065.      for constants.
  1066.  
  1067.      `g77slash' probably should automatically convert Hollerith
  1068.      constants that contain slashes to the appropriate `CHARACTER'
  1069.      constants.  Then `g77' wouldn't have to define a prefix syntax for
  1070.      Hollerith constants specifying whether they want C-style or
  1071.      straight-through backslashes.
  1072.  
  1073.    The above implements nearly exactly what is specified by *Note
  1074. Character Set::., and *Note Lines::., except it also provides automatic
  1075. conversion of tabs and ignoring of newline-related carriage returns.
  1076.  
  1077.    It also effects the "pure visual" model, by which is meant that a
  1078. user viewing his code in a typical text editor (assuming it's not
  1079. preprocessed via `g77stripcard' or similar) doesn't need any special
  1080. knowledge of whether spaces on the screen are really tabs, whether
  1081. lines end immediately after the last visible non-space character or
  1082. after a number of spaces and tabs that follow it, or whether the last
  1083. line in the file is ended by a newline.
  1084.  
  1085.    Most editors don't make these distinctions, the ANSI FORTRAN 77
  1086. standard doesn't require them to, and it permits a standard-conforming
  1087. compiler to define a method for transforming source code to "standard
  1088. form" however it wants.
  1089.  
  1090.    So, GNU Fortran defines it such that users have the best chance of
  1091. having the code be interpreted the way it looks on the screen of the
  1092. typical editor.
  1093.  
  1094.    (Fancy editors should *never* be required to correctly read code
  1095. written in classic two-dimensional-plaintext form.  By correct reading
  1096. I mean ability to read it, book-like, without mistaking text ignored by
  1097. the compiler for program code and vice versa, and without having to
  1098. count beyond the first several columns.  The vague meaning of ASCII
  1099. TAB, among other things, complicates this somewhat, but as long as
  1100. "everyone", including the editor, other tools, and printer, agrees
  1101. about the every-eighth-column convention, the GNU Fortran "pure visual"
  1102. model meets these requirements.  Any language or user-visible source
  1103. form requiring special tagging of tabs, the ends of lines after
  1104. spaces/tabs, and so on, is broken by this definition.  Fortunately,
  1105. Fortran *itself* is not broken, even if most vendor-supplied defaults
  1106. for their Fortran compilers *are* in this regard.)
  1107.  
  1108.    Further, this model provides a clean interface to whatever
  1109. preprocessors or code-generators are used to produce input to this
  1110. phase of `g77'.  Mainly, they need not worry about long lines.
  1111.  
  1112. 
  1113. File: g77.info,  Node: sta.c,  Next: stb.c,  Prev: lex.c,  Up: Overview of Translation Process
  1114.  
  1115. sta.c
  1116. -----
  1117.  
  1118. 
  1119. File: g77.info,  Node: stb.c,  Next: expr.c,  Prev: sta.c,  Up: Overview of Translation Process
  1120.  
  1121. stb.c
  1122. -----
  1123.  
  1124. 
  1125. File: g77.info,  Node: expr.c,  Next: stc.c,  Prev: stb.c,  Up: Overview of Translation Process
  1126.  
  1127. expr.c
  1128. ------
  1129.  
  1130. 
  1131. File: g77.info,  Node: stc.c,  Next: std.c,  Prev: expr.c,  Up: Overview of Translation Process
  1132.  
  1133. stc.c
  1134. -----
  1135.  
  1136. 
  1137. File: g77.info,  Node: std.c,  Next: ste.c,  Prev: stc.c,  Up: Overview of Translation Process
  1138.  
  1139. std.c
  1140. -----
  1141.  
  1142. 
  1143. File: g77.info,  Node: ste.c,  Next: Gotchas (Transforming),  Prev: std.c,  Up: Overview of Translation Process
  1144.  
  1145. ste.c
  1146. -----
  1147.  
  1148.